I found "Don't Make Me Think" by Steve Krug to be a helpful guide. As an engineer who was shy to approach product design, I felt the language really helped demystify things.
Unfortunately, if you don't have permission to download then you may be committing piracy. In this case, entire countries apparently don't have permission.
If the system is guessing location based on IP address, then granting permission based on that guess, then I expect their permission grant should be valid. How would a user know that they have bugs in their permission system?
If you connect directly first, are told "no", then bypass the system with a VPN: You probably understand that you aren't supposed to have access.
What will happen if you commit this type of piracy? I don't think there's a loss of revenue, or damages so pursuing pirates likely isn't worth it.
One of the unexpected benefits for me has been that I can lock any OAuth enabled app to a container for the OAuth provider I use. To login, I check which container I'm in and click the associated button.
Before this I'd always forget which OAuth provider I previously used. Did I Login with Google to DigitalOcean or did I use GitHub? Worse, I'd often click the wrong button and get logged into a new/empty account. I never came up with a good rule for which OAuth provider I should use, so it's a guessing game.
Locking the app to the container means I don't really need to think.
Same MacBook, same SSD upgrade. I haven't replaced the battery, I tend to stay near an outlet anyway. Debian and Ubuntu work great on it, so I moved off OSX.
> To be fair, if the rest of your pipeline runs in the megabytes per second, then memory allocation might as well be free from a speed point of view.
This is important, but I think sometime people struggle with this sort of thinking. I struggled to explain a similar concept to a junior engineer recently. He was very keen to try to optimize part of a process that wasn't the bottleneck. I tried a couple approaches, like benchmarking various parts under different conditions, modeling it to calculate how speeding up different components would take.
I wasn't convincing, unfortunately, so he implemented some changes that sussessfully sped up one part but didn't improve end to end performance. I think sometimes you need to see it with your own eyes.
Presumably, if the customer doesn't have the right to repair then the manufacturer would be able to make parts that are exceptionally difficult to repair without specialized knowledge and tools. Or worse, enforce cryptographic locks on any software/firmware to prevent unauthorized changes.
I think right to repair is about ensuring that the customer can make reasonable repairs to the product, and the manufacturer not infringing on their rights when designing the product.
How are folks using light weight cloud resources approaching password hashing? The `10s of gigabytes of RAM` feels like an expensive requirement. Even lower memory, high iteration count sha256 seems expensive for something like AWS Lambda where you're paying by the millisecond.
From the UX perspective there's also the issue that adding a second of latency during login or registration could increase user drop off.
How many sites really incur the higher costs and higher latency?
Agreement from me, although I'd avoid double booking. Double booking means that other people are expecting you to attend, they may wait to see if more people join, or need to reschedule if the right audience isn't able to make it. I think it's best to pro-actively reject meetings versus only showing up for one.
I'll add my (32/M/USA) perspective as someone who subscribed to duolingo plus last month. I'm learning Arabic ahead of a _potential_ move with my spouse to an Arabic speaking country.
First Duolingo is fun to use. I didn't enjoy classroom based learning in high school. Duo gamifies the process really well, it's on my schedule, and I have a concrete reason to want to learn. Duo has been reducing my time on social media as well, always a bonus when picking up a good habit.
The $7/month premium subscription was worth it. I'm investing 30 minutes a day in the app, and ad-free means I can get through more lessons. I have unlimited lives so my learning isn't interrupted if I struggle on a hard lesson.
I'm not expecting to become fluent on Duo alone. But I think I'll get a great handle on some basics. My wife is already fluent, so that's helped me speak and figure out some things I struggled with.
I also tried the Rosetta Stone app. I didn't think that one was fun, it throws you into hard content quickly, so I haven't been using it. If our move happens, I'll enroll in a more traditional environment, and I may take a second look at the Rosetta Stone app. For now I'm happy that I have something that's making me increasingly comfortable with the idea of speaking Arabic.
Any thoughts on how customers should think about securing their skills? ChatOps exposes skills that may provide deep access to deploy code or modify system configuration. Slack doesn't have the same security as an SSH session (password protected private key). I'm seeing concerns around phone theft, evil maid, spouses, or former employees who haven't had Slack access pulled.
From my end, I think these are solvable but may require thinking about the problem differently. How are you thinking about security?
I think it's best to migrate to a preferred formatting slowly, versus touching everything at once. I've had open pull requests that I've started over due to aggressive reformatting like that. Between that and breaking tools like 'git blame', it can be painful.