- Here's a few dozen use cases based on my own use of smart home devices:
- Hands are full or dirty while cooking. Voice activation is more convenient. True for not just timers, but every other aspect - music playing, controlling home devices like lights, watching something on YouTube, etc.
- The above also applies to any case where my hands can't readily access my phone, such as wanting to listen/change music when showering.
- As the other commenter said, sometimes the timer needs to be "room-specific" rather than on my phone (which stays with me)
- The device has a decent speaker, so makes a convenient Spotify device. The voice activation is sufficient, though I can also control the device via Spotify on my phone if there's occasional blips.
- Combined with smart light switches, I have convenient control over various aspects of lighting in my home
- Combined with Chromecast / Google TV, it provides voice activated access to pause/play/change what I'm watching.
- Basic internet queries, such as how long it will take to drive somewhere or when a certain place will close, work well also.
None of these use cases _individually_ is so amazing I'd spend $100+, but the combined total value is great for me.
- If it takes 1 hour of effort to save 5%:
- Doing 1 hour of effort to save 5% on your $20 lunch is foolhardy for most people. $1/hr is well below US minimum wage. - Doing 1 hour of effort to save 5% on your $50k car is wise. $2500/hr is well above what most people are making at work.
It's not about whether the $2500 affects my ability to buy the car. It's about whether the time it takes me to save that 5% ends up being worthwhile to me given the actual amount saved.
The question is really "given the person-hours it takes to apply the savings, and the real value of the savings, is the savings worth the person-hours spent?"
- GDPR isn't a blanket ban on cookies. You don't require a cookie notice for strictly necessary cookies, which you have a "grounds of legitimate interest" for: https://commission.europa.eu/law/law-topic/data-protection/r...
Fraud prevention is listed as an example of a "legitimate interest."
So no, by my layman's interpretation, they would not have been bound by GDPR to notify the user of cookies or other fingerprinting used solely for anti-cheat. They'd run into trouble if they use that same ID for marketing/advertising without consent, though.
- What makes you say that? In my experience, the spam button works fantastically. There is a gym of some kind that has me on their mailing list, refuses to honor unsubscribe, and sends me probably 2-6 emails a month. They've been doing this for years, but Google correctly gets every single one into spam because I marked one (several?) as spam years ago.
Most, if not all, political junk email also ends up in my spam folder after judicious use of the spam button a few years ago.
- Minimum thresholds, and exceptions for less liquid assets (private equity) - ideally, again, coupled with thresholds.
The same way we have exceptions like CA Prop 13 for increasing property taxes.
These problems aren't impossible to solve. It's wild how people will find any tiny excuse to give up on making a change to try and make tax code more fair. If there are edge cases that a blanked change to the code makes worse, that's NOT a reason to just throw our hands up and say "whelp, can't make changes" - it just means we need to add a bit more nuance.
- Why would there need to be a carve out for home/auto loans?
1. No one really borrows against the value of their (paid off) car. 2. Property taxes already, generally, are against the assessed value of the home, so it's already happening for that case. There are some minimal exceptions, like CA Prop 13, of course, but generally speaking, if I want to take out a second mortgage or something, my home's value is already appropriately "stepped up."
- I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact.
Monoliths are simpler to understand, easier to run, and harder to break - up until you have so many people working on them that it becomes difficult for a team to get their work done. At that point, start splitting off "fiefdoms" that let each team move more quickly again.
- You can control the block size for this, though: https://man.openbsd.org/sshd_config.5#PerSourceNetBlockSize
- Because it was used as BOTH an identifier AND proof of identity, for a long time. If it were used properly as simply an identifier, you'd be right, but there are still many cases where knowledge of the number is used as proof (or partial proof, along with birthdate/address/etc) of identity.
- The article doesn't claim that you should make a language and actually use it - the author focuses on the learning experience. He makes valid points.
No, it's probably not the right learning experience for everyone (clearly, it won't be yours), but there's definitely value in it for some people. And if reading the article nudges a few more people to take that learning dive, I think that's a good thing.
- I agree. The other cases may be mildly surprising, but ultimately fall firmly into the category of "once public on the internet, always public." Deleting a repo or fork or commit doesn't revoke an access key that was accidentally committed, and an access key being public for even a microsecond should be assumed to have been scraped and usable by a malicious actor.
- If someone steals my card, and uses it to pay for Netflix, how will I log in and cancel?
The simplest, safe route is to not give companies the newly updated number. If my Netflix lapses because I forgot to update the number after a card change (whatever the reason), they can email me, and then I will log in to my account and update the card on file.
- The bug was originally filed against Netscape Navigator per this comment: https://www.hackerneue.com/item?id=40431738
- The pitfall is pretty simply stated: "It masks the problem with logic, adding some risks of anomalies." When one puts a bandaid over bad data, the problem isn't solved, it's masked. Depending on the issue, it could bite you later, in unexpected ways, at the worst possible times.
In this particular case, the "bad data" is a table/column/view that exists (or doesn't) when it should(n't). Why does the table exist when it shouldn't yet exist? Did it fail to get dropped? Is the existing one the right schema? Is the same migration erroneously running twice?
After each migration, your schema should be in a precise state. If the phrase "IF [NOT] EXISTS" is in your migration, then after a previous migration, it wasn't left in a precise state. Being uncertain about the state of your schema isn't great.
If you buy a home instead of investing, you've got a locked in, controlled rate for your housing expenses. (Yes, there's some variability with property tax and insurance). In difficult times, you can still plan very carefully around your housing costs and wait for better times.
If you rent and invest, your housing costs can be highly variable and uncontrollable over time. Your investments may not cover increases in housing costs.
A critical factor is that housing is more or less a _required_ cost of existence - just like feeding oneself. It is not something where one can necessarily "invest in other areas" instead. There are extreme cases (living out of an RV or in a tent on the side of the road), but for the most part those extremes are not representative of how someone wants to live. One can only downsize so much, and downsizing your housing investment comes with very real changes to quality of life (storage space, commute time, access to grocery stores, etc).