furstenheim

Coming from node world, global dependencies like in java and python are a total deal breaker.

In node same library in two different versions can coexist in different parts of the dependency tree and that's totally fine (there are some small exceptions). You give up some space but the gains are incredible.

In contrast, in Java I've got runtime errors because a library down the tree was importing some other library with the same package name.

Npm ecosystem already has the solution. Use namespaces @yelp/infra-js where @yelp is the npm user.

It's not possible for an attacker to publish on that name in the public npm

There are such stories. Roald dahl has a very nice short story about it https://www.roalddahlfans.com/dahls-work/short-stories/the-g....

Good point

I like to think of it in algorithmical terms. Maintaining the code is O(n) on the size of the code

It's different calling someone out of the blue, than calling someone you're meeting in 30 minutes.

Not specially hard. And you're comparing different stuff. I'm not using a different phone because it's easier, but because having a smartphone is distracting. It's noticeable, but in case you need a link.

https://www.sacurrent.com/the-daily/archives/2017/06/28/just...

What I do is tell the other person to reach me on a call if there's any change of plans. That's been enough. Also in case we don't see each other.

What I do is to tell the other person that I'll be using this other number and to call me if there's any change of plans.

Edit: I actually have two phone numbers. So the new phone is still at home receiving everything

Something that I've found useful when meeting someone in real life, I take an old phone that's only capable of making calls. That way I avoid any possible communication issues, but I don't get distracted at all.

This comes to prove the basic and probably only lottery strategy.

If you choose (which you shouldn't) to play the lottery, then avoid common sequences like 5,6,7,8,9,10 or dates. In very unlikely case that you win, you'll most probably have to share the prize

Datadog is providing tracing at least at a function level, so it should be possible

Something that I've thought sometimes. A tracing mechanism in all branches. And you check in production which lines are never executed. Of course, some things are tricky. For example, handling of cases that should never happen, but maybe those could be annotated.

This has really struck home.I'm missing another one.

Your dataset is tilted 90° and in some other part of the globe: you probably swapped latitude and longitude.

Tip: latitude sounds like "altitude" so it has to be the y coordinate

As they say, warmest October among the past years, coldest October among the ones coming...

Shameless plug, sometime ago I ported webscraper to work with node and puppeteer https://www.npmjs.com/package/web-scraper-headless.

That way one can build the scraper with the ui in the browser from the extension https://chrome.google.com/webstore/detail/web-scraper-free-w... and scrape on the server.

> Domino effect: one bug can take down the entire system at once

It bothers me that this is always set as a selling point for microservices, when it's actually the opposite. With monoliths (or at least monorepo) it's easier to test complex flows. When you split into microservices, they are still there, but there are so many boundaries in development that you end up testing in prod. For me it's a bit like unit tests vs integration tests. It means to naively think that all those unit tests somehow interact together to define the functionality that you want

This one was super useful for me

https://www.amazon.es/PostgreSQL-High-Performance-Gregory-Sm...

I think that they have a newer edition for postgres 10

For the later interviews, once you're left with a couple of candidates to decide from, I like product driven interviews. You choose a complex business requirement that is already implemented.

You discuss different architecture options, feature trade offs...

It's easier for both parts to connect, it will give you a glimpse of how the candidate faces requirements from other teams and you give him a taste of the inner workings.

Of course, I'm not saying the opposite. But you're sacrifying development options in the process

One thing that bothers me about serverless functions is that there is virtually no concurrency. Once you return you have no assurance that your code will keep on working.

If you want to perform actions that might be throttled (cloudwatch for example) and are not critical for the response, you cannot have a singleton processing them after you return, because they might not be processed.

Alternatively, you could have some ui that allowed writing to the wiki and it converted it to a commit. Basically the same way that editing the readme can be done at GitHub. In any case, as mentioned in a different comment. Most of the wiki is edited by developers anyway

Take a look here https://hnhiring.com/ it might be helpful

How ironic, one of the first things that I missed in Java was that. Nor the compiler error, nor the standard linter (checkstyle) prevents unused variables.

What they said is that if it's gummy, it will induce you to chew during the night. They claimed that the only approved one was hard, but I didn't verify that.

I have less pain. But I won't risk sleeping without it

A lot of the results of this analysis are a consequence of actually good UX in dependency management.

In NPM publishing a library is really easy. To compare with java, I recently had to follow a [three part medium article](https://proandroiddev.com/publishing-a-maven-artifact-3-3-st...) to publish. NPM: one login, one cli command and you're done. That lowers the bar to create a library, there are a lot of low quality libraries, but there's also much more diversity and really cool libraries. In java I've seen a lot of copy pasting. In Node you just create a library. You can worry a lot about 1k dependencies, but a lot of those will be one liners.

In node, it's basically impossible to have conflicts with dependencies. Again if we compare to Java. In Java namespaces are global, if there are two libraries sharing the same package name they will collide. That makes deep dependency trees actually a liability. I've seen recommendations of not using guava if you are writing a library, because they change the api so much that it will most certainly give problems if your user wants to use it as well, so much for a library. In Node, in contrast, if there are two different libraries that require different versions, they will each have their own dependency version. That has the cost of space, but there it saves hundreds of hours on conflict resolution. You can even have two different versions of the same library with different name, in case you need to partially migrate a project.

Making it easy to create and consume libraries has of course a clear consequence, more deep and big dependency trees.

Same here. I have the impression that it has improved by

a) having a softer pillow.

b) having a hard guard. Before that I had a gummy-like guard. According to the new dentist the was making the bruxism worse.

Very interesting. I'm starting now a project to organise my recipes. With https://github.com/domchristie/turndown it transforms the html from clipboard into markdown, they result is really good and it's generic to all recipes.

Of course you don't have structure of the recipe and it does not simply work with a url.

I'd rather track it in the repo and let the pipeline deploy it. No need to modify it by hand.

You can always move it to a variadic function and do

    await parallel(first, two)

If your concern is clunkiness, I'm curious about callbacks, they're definitely more complex to use.

I understand your point that not knowing how promises work can lead to not optimizing them, but going from one to the second can easily done on another iteration. On the other hand, not being capable with callbacks can easily lead to (callback) hell, then you need to first fix the mess, then optimize.