mradzikowski

> What many of today's software authors want/expect is free testing.

Many of apps and tools are open-source and free. While I assume everyone wants to provide best experience, it's hard for me to justify being angry for bugs and problems in tools that I got for free, not bought them.

Secondly, the industry realized that going fast, releasing often, measuring results, and improving over time is a winning strategy. No matter how often we as users will complain that "they changed something again", we still want to get things fast. Deploying new version once per year is not something we would really like in most cases.

And fast development cycle inevitable comes with bugs, but they can be fixed quickly, not in the next year. Because even if you spend 2 months on testing your app, it will still contain bugs that will surface after the first real user touches the app.

As mentioned in the article, story-pointing is not about finding the perfect score for each task.

From my experience, it was always about uncovering potential problems or, contrary, easy solutions, that people think everyone understands, up to the moment when one person estimates "3", and the second one "8". The discussion at that moment is the most valuable part of the estimation, not the final story points value.

Isn't it more like a problem with using a single account by multiple people? Or lacking the feature to add access for multiple users to platform?

I remember watching a TED talk about it. 5 years ago [1].

While it's interesting, I don't think the "forget WiFi, meet LiFi" will happen in another 5 or 15 years either. I want to connect to network sitting on a toilet, and don't want my neighbor to see my traffic because I have my blinds raised.

Those problems could be mitigated, but I doubt that they could be mitigated for $30-$50, which is a price of a standard wifi router.

[1] https://www.ted.com/talks/harald_haas_forget_wi_fi_meet_the_...

The main point about the cookie notice (under GDPR) that is ignored by smaller sites is that you need to first ask for permission, and only then store cookies. In practice, that means you have to get consent to enable Google Analytics (and similar trackers).

That's why any bigger website will have a huge popup that will require you to consent before doing anything else - they need you to consent and then they enable trackers.

Smaller websites just don't care and put a small cookie notice banner stick to the bottom, and enable GA anyway. Most users probably won't even bother to click it, as it's not disruptive. It's therefore not GDPR compliant.

There will always be users that are too lazy to sign up by email and ones that do not use Facebook and/or Google to log in. Any obstruction of the sign up process can reduce your conversion. But you do not have to handle all the states by yourself. Delegate it to Auth0 or something similar.

I understand the motives (at least the official ones) behind those changes, and I agree with most of the points there. I would say that to some extend, joining social/political discussions by companies becomes marketing.

My biggest issue is that companies do not live in a politics-free bubble. The bigger the company the more it cares and tries to influence the politics, either publicly or not, because politics influences the business.

But business influences politics too. And I think this is a reason that employees want the companies to take a stand. A company employing 10k people can make a bigger impact than those 10k people themselves, so people want to leverage this.

Theoretically, it should be a bad thing, in democracy, we want every vote to count equally. But in sad reality, individual people choose politicians, but after that, the politics is shaped by powerful. 10k people are not powerful, the company they work for - may be.

You can run your code locally and still interact with real AWS services. For example, using Serverless Framework, you can do "sls invoke local", and your calls to DynamoDB etc. will work fine.

The problematic bit is the input event. You can't call real API Gtw. to trigger your Lambda code locally. You need to write/copy the request as JSON and provide it as input. It's more annoying with triggers like Kinesis Stream, but doable.

I personally don't like Localstack, it's safer to use real services.

Hey, I've added MIT license for all my gists (https://gist.github.com/m-radzikowski/d925ac457478db14c2146d...), so feel free to use it.

Well, I agree with your cron argument. On the other hand - sometimes I have some utility scripts, for example to trigger some processing, that I want to run multiple times at the same time, with different arguments. So lock is not a universal thing for me. (I'm the article author btw)

Hey, the flag meanings are explained in the article I linked in the post: > For details on what options exactly set -Eeuo pipefail changes and how they will protect you, I refer you to the article I have in my bookmarks for a few years now.

Link: https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_p...

About "just like JavaScript" - it was sarcasm ;-) I write in TypeScript daily and still make fun of JS. But I agree, Bash is worse!

I'm this blog post (and script) author. I got some opinions and code review feedback here, on Reddit, and blog itself. And I appreciate it!

I updated the script template applying the most commonly mentioned things, like removing "cd" to the directory. See details in the article.