pmoleri

The statements are true. Period. There's no need to imagine a place where all three overlap, they are already true. Specially since the last one is just a possibility.

Around 2012 my 6GB Ram laptop was struggling with Chrome, I switched to FF and got much better experience there. Then with FF Quantum release I adopted it definitely.

That used to happen to me with Slashdot too. I'm so happy that today I didn't even realize HN was down, I think I tried once, it didn't load and went do something else, I assumed it was some local DNS or internet issue.

Sharing code is great, I've moved processing between backend and front-end or even share the same code in both. Makes SSR+SPA possible using the same code. Typescript is a must for me, but I don't need Deno for that. I haven't used beyond scripting but for the time being I don't see a mayor benefit over node or ts-node other than easier/zero project setup.

It's not contradictory, the UI is single threaded but on the dispatched events you can perfectly have long running tasks that can perform parallel work and affefct common memory.

It's also my understanding that if you stick to async/await and don't create your own tasks, the synchronization context will be the one of the UI thread thus never run in parallel. However, this doesn't prevent you from doing so.

I think it depends on the language. What you say is true for JS because it's single threaded but .Net has a thread pool, that means that you can have concurrent and even parallel tasks attending different events from your single thread UI.

async/await reveals to the consumer that at some point it will exit the code realm for some I/O task and that the result will be asynchronous, you like it or not, this is what really happens. Threads approach conceals that fact and wait for the return without you noticing. So, one disadvantage I see, is that you'll need to guess where the time consuming tasks will be done and create threads for them. The most perfomant code will be the one written by who knows better the underlying code.

Previous discussion 2020-10: https://news.ycombinator.com/item?id=24671279

Takeout + store encrypted in AWS S3 or even Glacier? Preety cheap storage and supposedly high redundancy. I guess it's better to not use Gmail email address to create that AWS account.

> Backups can be made independent of source control.

To be fair there's a middle ground. You can just commit as WIP and force push to save progress. Then undo that commit and start making the individual commits. Everyone's happy.

Until the opposite happens. Some big security hole is fixed in the dependency, npm gets the fixed version by default while Go is stuck in the tested unsecure version. Or Go mitigates the somehow?

I'm not sure what you mean. Vaccine was a success, it saved millions of lives. What's becoming endemic is a less deadly variant, otherwise we would be back to square 0, confinement and developing a new vaccine. So, instead of calling it a failure I would call it success with a lucky ending, if everything continues like this of course.

Using Kodi in my tv box and setup SMB to a shared folder on my Windows laptop. It was an easy setup and pretty frictionless later. I usually still use VLC to get the subtitles upfront saved with the same filename as the video file. Whatever I get in my laptop I can see in the TV later. Chromecast is also an option, not sure if there's some quality loss in that case.

I consider fleshing out customer requirements part of the engineering process. You cannot expect the customer to properly communicate what they want/need. That doesn't mean Scrum, you have many other tools at your disposal, presenting the customer with scenarios to challenge their requirements, use interactive prototypes or even paper ones. All of them far cheaper than implementing the wrong thing.

I agree about the pitfalls of not seeing something usable until it's very late and how to measure progress. The opposite is also true however, you make some easy non-scalable PoC and it looks like a huge progress when it actually can't or shouldn't be used as a foundation for anything.

I always wonder, Are this practices creating inflation? Once the price has gone up it's difficult to ever come back to it's previous price.

The money is coming out of non-secretive countries, right? Eg. by end user credit cards o by 3rd companies buying ads or data.

So, `yarn upgrade` broke something, probably because some package down the road didn't respect SemVer. I guess failing to respect SemVer can happen in any ecosystem, now in other ecosystem you could have sealed dependencies that an upgrade can't break, but then it makes the whole upgrade action moot. In summary, you either, not upgrade, go deep in your lock-file and fix it manually, our you update your main depenency like you did. If your UI library doesn't support the new version of the framework, you either change the library or you bail out on upgrade for the time being.

It seems pretty reasonable process to me, I feel your pain on the wasted time and I wish github issues have something like "current answer" so we don't need to go through pages of comments to find out how to fix or workaround something. In any case, lock files are there to help and make everything more static like in other package managers that don't support the same kind of dynamism. Upgrade is just like wiping your lock file.

Only if the joined countries don't implement some kind of differentiated tax on products and services commiting from outside the list.

IMO it's a beautiful abstraction. You don't need to think about threads, just that your code will continue later when the result is available. In threaded environments like .net you can also create a CPU bound task that will be run in the background, yes in a thread pool, but you don't really need to know the specifics, it's something that you create, release the current thread (e.g. UI thread). For some IO tasks there's no even a waiting thread, so in that case thread would be the wrong abstraction.

I disagree, I think getting the license to stream the content is a much more difficult problem than the technology to stream it.

Wow, bold statement. Can you give examples of things it does wrong?

IMO, npm is a breeze compared to pip. With npm you know that `npm i && npm start` will start 95% of the projects cross-platform. It allows having different subdependencies versions in a way that just works. It encourages semver but at the same time you have lock file. Is highly customizable with rc files.

Perhaps I just don't have that much experience with pip, but it feels more like a tool to install packages, then you're on your own with some makefile or python scripts with no standard setup.

It's good to know. Unfortunately, in Uruguay we're not part of the 28 countries where Brother has recycling in place [1]. And I don't think we get any real alternative except for rogue refilling of the cartridges, or just recycle it as regular plastic waste.

Still, I consider having recycling in 28 countries to be pretty good.

[1] https://global.brother/en/eco/product/recycling

+1 for brother laser +1 for duplex

I actually find Wifi useful.

Question, what's the deal with the toner cartridges plastic? It looks like a lot of thick plastic. I get to buy a new one and throw the old one, or refill one with the "not recommended non-original toner".

Does the manufacturer offer some other environment friendly option?

Agree 100%

Having 20 supposeddly high risk issues about possible DoS when all come from a build dev-dependency is just totally useless. If only I could add whitelists, then it would be bearable. Like "I don't care about such kind of issue in a dev dependency".

This is a great example. It's incredible than in all latin america no other country has developed a vaccine, having huge countries like Brazil, Mexico and Argentina.

I agree with most of the article. Explain the why and tricky parts. Attempt self-documenting code, don't loose your head over it.

On other aspect, I can't believe this lived for 6 hours without the mandatory quote: https://xkcd.com/1421/

Enjoy.

I've seen people refactoring the code just to avoid writing a single line comment, like it's a dirty thing to do. After the refactor the new code is probably more readable, but not as good as it would have been with the comment.

VSCode git-lens. Mandatory extension. Either way, I think both are useful, although for documenting weird code I think code comments are more important. I the commit message you should explain why you change the code. In the code, why it works like that.