vmasto

I recently became a dad, and right now the only way my 30-day-old will sleep is with the sound of our kitchen range hood, so I built a small one pager that mimics white noise, womb sounds and our range hood. I hope I don't jinx this but works good so far.

Womb.FM - https://www.womb.fm

Ah, hardware products.

Can you explain why it makes a difference what the answers are?

When using an open source library assumptions should be:

- The code does what it advertises.

- The owner is responsible for the functionality.

- The owner's reputation is based on the quality.

You're making it sound that you're more sure for the above when the code is "hand-written" than LLM-driven. Why exactly? Do you tend to deeply understand the strengths and limitations of every coder whose software you're using in your projects?

As long as the owner is responsible for the quality of a project why does it matter how it was executed?

Stress most times doesn't reveal itself like that. What you're describing is short term excitement and perhaps anxiety.

Stress is a silent killer. It's basically being mostly unhappy, feeling unfulfilled and trapped. It's a spectrum that can range from simply being unhappy to being deeply depressed.

The dual landings for me were far superior. It was straight out of science fiction.

I'm very confused. Grade school problems? Didn't ChatGPT 4 ace the entire curriculum of MIT a while back?

Intelligence does not imply agency or consciousness.

I think you missed the fact that I'm talking relatively (i.e. within a software house as I say) and the quotes around "working class".

Still, If we want to be pedantic and literal (i.e. assume I'm talking about the Marxist definition) it still holds true, as class is not defined by compensation but by the role of the individual within the production process.

I don't work at Reddit but I take personal offense when someone so unfairly criticizes the "working class" of a software house like that (ie the non manager level software engineers).

What makes you think that whatever is wrong with Reddit is due to lack of talent? It almost never is.

* even at light speed

What would some common/helpful use cases be?

This was a 100m asteroid (city killer), not 1km.

Can you expound on the concerns?

IntelliJ supports editorconfig just fine.

I'm not sure why you were disappointed, editorconfig does not advertise the features you mentioned. For more involved autoformatting you need some kind of tool like gofmt or Prettier for JavaScript.

I'm not following, how does memorizing algorithms correlate with intelligence and skill in the engineering discipline of the job?

I don't think that's nothing, you learned to code better :)

I'm not following. Clearly the grandparent comment misconstrued the article as to have been written by a male, as did I. They are talking about the author.

For what it's worth the url and the author's handle threw me off. "harthrur", simply thought of someone named Arthur in their first name, not the last. I completely ignored the website's name as well it seems.

1 trillion chances per planet

Not meaning to be condescending, that's not how probability works or is expressed.

Also, the fact that the ocean "is a large place" says nothing about how probable or not the events to create and sustain life are.

I understand most people have this gut feeling that because the universe is vast and ancient there must be something out there (and I have it too), but we just don't know.

We just have no idea exactly how hard life is to develop and be sustained. We just started having theories (a handful at that) about how we transcended from chemistry to biology. The prevalent theory for example is that the moon's unusually big size and proximity was the catalyst for that to happen. How many planets have extremely big moons in such close proximity? How many million other factors played a role assuming the tide theory is even close to accurate?

It's just an infinitely complex problem and we just don't know.

I don't get this point. The probability argued would take this into account. It could be that the probability is _that_ small that even if you keep rolling you don't reach it.

A NAS setup or Backblaze. Personally I use both for redundancy.

The technique is called "windowing" and it's not extremely hard to implement properly. For react we have react-virtualized and react-window, and I'm sure there are other libraries for different UI frameworks.

I'm running infinite scroll in production serving thousands of photos and it works pretty well, constant 60fps, low memory consumption and you could literally scroll infinitely (given infinite content).

They meant its API surface, not filesize. React is ridiculously small and simple for what it can do.

Exactly. Most actions in idle game mode (i.e. when there's no active battle, micro or macro to be done) are null, the gamers simply repeat random meaningless keystrokes; this helps with being always alert and ready for anything that requires a rapid response.

An AI doesn't need to do this.

Source: Ex pro Starcraft (Brood War) gamer.

The answer (in my opinion at least) is that yes `==` should be avoided, if for nothing else then simply because it's totally unnecessary and only adds a mental overhead.

I haven't found a use case where it would be necessary, and when it would seem it is, it's indicatory of code smell, e.g. badly formatted JSON responses.

Maybe a use case for abstract equality could be for comparing HTML data attributes (which all return strings by default using the web APIs). In this case it would be far better to abstract your HTML data attr wrapper to something like jQuery's .data method which will always return correct specific types rather than strings (e.g. data-bool="true" will return _true_ (bool) instead of "true" (string)). I believe many of JavaScript's old quirks are due to trying to interoperate with HTML better.

In most cases if (!foo) is what you are interested in and it's cleaner.

In most cases yes, but there are cases where you simply want to check explicitly for undefined or null (e.g. does a variable or property exist or has a value, even if it's an empty string or 0). !foo means your variable isn't: an empty string, the number 0, the bool false, null or undefined.

It's also worth noting that `===` is not deep equality. It's merely referential equality (the equivalent of .is in other languages) for all non-primitive types.

e.g. [1,2,3] === [1,2,3] will always return false since the two arrays are different objects and point to different references. "123" === "123" will return true because they are both Strings (considered primitive types in JS).

Abstract equality will always fallback to strict equality when the types of the compared values are the same, but using strict equality everywhere avoids headaches that might come up during runtime.

Edit: I'm not sure why you're being downvoted, you're simply asking a question.

From now on I'm going to include at least one of these in each interview I'll be conducting - for extra points of course.

There's absolutely 0 benefit from an engineering standpoint in having type coercion memorized in JavaScript.

I'd personally immediately terminate every interview that posed such questions ({} + [] + '' or whatever).

I mean no offense, but I'd ask you to reconsider. People who ask trick/puzzle questions and hacks in interviews do not understand (or haven't thought deeply enough) how to properly screen JS developers which eventually goes through to the team itself. There are at least a dozen more interesting topics to question on if you want to assign extra points than useless stuff that should never be into production in the first place.

If you are a professional developer, you can consider these examples as a great resource for interview questions and quizzes for newcomers in your company

No, do not consider these examples as a "great" resource for interview questions. They are nothing more than tricks and hacks abusing the bad aspects of the language and anyone who includes them in an interview has failed in screening JavaScript developers, at least in my book.

A JS developer should understand that JavaScript has some flawed, unfixable core concepts and educate themselves on how to avoid them, not use them in actual production code or memorize every coercion scenario.

Some simple rules:

1. Always use referential equality checks (triple equal `===`). In idiomatic JS you can also use double equality only when explicitly checking against undefined or null (foo == null). It's the only use of abstract equality that I find acceptable.

2. Learn how the `this` execution context works. Kyle Simpson explains it very well in YDKJS (https://github.com/getify/You-Dont-Know-JS/blob/master/this%...). There are four simple rules that matter and are straightforward to grasp.

3. Familiarize yourself with how type coercion works in JS but avoid it. The spec is quite easy to follow in this matter and follows very specific, documented rules. e.g.:

https://www.ecma-international.org/ecma-262/8.0/index.html#s... https://www.ecma-international.org/ecma-262/8.0/index.html#s...

Use strictly as reference.

4. Stop using plain ES5, the language currently is ES2017. ES2015 and beyond provide modern constructs that make most of ES5's weirdness obsolete. For example, never use `var` anymore, `const` and `let` are superior initializers.

By following the above rules a JS developer should be fine in 99% of cases, in my experience. Yes, JavaScript will possibly implode on you on the rest 1%, but I'd be hard pressed to find a (similarly popular) language that doesn't. If one finds that to be unacceptable, enabling types via TypeScript or Flow should make their life even easier.

Please can you make the async version return a Promise. It's 2017 for cryin' out loud!

five.asPromised?

Typical case. The original developer has abandonded the project, maintainers make a complete mess of it, project ends up electing Trump as president of the United States.

Regarding your point in 2: do you store your docs in a directory called Documents or Document?

It's not. If you think it is you probably store JWT unsafely instead of in an httpOnly secure cookie.