I sincerely hope that having produced a comment like that, you are not using ad blockers of any kind in any browser, including the reduced functionality Chrome uBlock Origin on manifest V3.
For me, ads broke the informal social contract between provider and end user years ago. Small, unobtrusive advertisements might've been okay, but ads eating an inordinate amount of my time and bandwidth, which exfiltrate my personal information, and which are served to me via SEO tricks and dark patterns are not okay. If sites want to ban me for not viewing their ads, fine. In the meantime, I won't lose any sleep over using my adblocker.
For you, if you are lecturing us on the moral imperative of viewing ads, then you better be viewing those ads yourself rather than only espousing cheap rhetoric.
Especially egregious was a 10-year look back so even if you left years before the taxes would take effect, they'd still fleece you.
The way California's finances are going, and the way the state is degenerating, it's only a matter of time until they get serious and pass some form of this. It probably won't pass legal muster, but they'll do it anyway and spend years fighting it in courts.
> the annual risk of a given person being hit by a meteorite is estimated to be one chance in 17 billion, which means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%.
So in a theoretical sense, no, but in a practical sense, yes. The same is true for any custom ID format like yours as well. 128 bits is enough to never hit a dup though, so you don't need to go crazy.
Your database should be what authoritatively guarantees uniqueness at the end of the day — generate UUIDs assuming no collisions (which will ~always be true), but store in a UNIQUE index so things'll fail in case of a duplicate or a bug that results in trying to store the same ID twice.
Real UUIDs in the DB are definitely the right answer. I couldn't help but think the article has the right idea but reaches the wrong conclusion — it is possible to use user-specified IDs, but make sure you're taking them as UUID and storing them as such too.
That said, I understand how they got there. Although using real UUIDs in the backend is obviously the right path, it's amazing how rare their use is in industry. Developers either (1) don't know about the UUID type, (2) don't understand the advantages of such and therefore use a string instead because it's more familiar, or (3) in hubris, cast off the use of UUID because they know better and are doing their own thing.
We're using real UUIDs where I work now, but after a full ten years of industry experience, it's the first job where we're doing it right, despite previous jobs being at top name Silicon Valley companies who you'd think would know what they're doing.
Is anyone able to get a little more specific about the kinds of "creators" he's talking about and what they do exactly which drive these abuse problems?
I read the article, but felt like there wasn't quite enough information to understand what a YouTube person does to cause trouble, although I totally believe it. I know a bit about cameras, but nothing about this adjacent "rumours" subindustry.
That seems to be right, but your parent's point still stands — the house may have burned down during an eight year absence, but it really doesn't seem to have "vanished". The title and lead into the story have been heavily sensationalized for click purposes.
Exactly this. Multiple requests with the same idempotency key are still different requests, and you want to be able to track them independently.
Also worth noting that a header named 'Request-Id' is already a widespread convention. You'll see one back from many popular APIs like AWS or Stripe, and definitely want a name for the idempotency header that differentiates itself from that.
I agree — the 12" is still Apple's best ever form factor. I even considered buying another one as the line was winding down. (Though was glad I didn't after the M1 came out.)
But to be fair, the comment you're replying to is talking specifically about the 12" MacBook's keyboard, which is indeed awful. I'm typing on one right now, and even after years on the thing, it's a perpetual reminder of how they're slower to type on, and kind of make your fingers hurt.
Remove the butterfly keyboard, add a second port, and the 12" MacBook gets unequivocally better.
Similar situation here. I use 1Password every day, but I only trust it to autofill simple login forms. Where something more complex is happening, I tend to copy information over field by field.
This was trained into me over the years as I saw 1Password do too many things that were wrong or even sometimes scary. The nominal benefit you get sometimes when it works properly isn't worth it.
And yes, web providers should give their web forms better names and better semantic information (e.g. `<input type="email">`), but even in 2021 it's just not always the case.
It's very verbose, and includes a lot of opaque language that almost seems designed to confuse (I know it wasn't actually, but it's pretty bad). For example, an alphanumeric variable type is called a `PIC` for "PICTURE". You can store an alphanumeric as a `PIC A`, or a numeric-only using a `PIC X`. Fields in a record get a "level number" that defines their behavior, and you just have to memorize which does what. 01 is a top-level record. 05 defines a subgroup. 88 is a conditional record.
There are many parts of the language that are clearly anti-features in retrospect. A 66 level number allows you to redefine a field in a previously defined record. Convenient in some cases maybe, but something that will clearly lead to maintainability problems as the shape of a record doesn't match its original definition in code. Another example is that COBOL has a huge vocabulary, with the original idea that you could write things as much like English as possible (e.g. use a `GREATER THAN` instead of a `>`), which is one of those things that probably seemed like a good idea at one point, but which every modern language has abandoned or is abandoning (through the use of linters, etc.).
The article makes quite a few salient points, but on the other hand, if there's ever been a language that got almost everything wrong in about as objective a sense as you can get when speaking about these things, it's this one.
Instead of inspiring the next generation of COBOL programmers, IMO there's a good alternative argument to be made for getting a bunch of smart people together to write a transpiler that could transform huge legacy COBOL codebases to something more maintainable, like how the Go team transpiled from C to Go, and vanquishing this language to the history books. Obviously very difficult, but something that'd pay off in the long run.
And not to mention that like everywhere else in San Francisco, there will likely be in no enforcement of these traffic rules whatsoever, so in practice private vehicles will still he allowed too.
Also, traffic on all cross streets is still open, and on most of them it’s common convention to trail red lights by ten seconds or more, well into the start of pedestrian signal as it’s changed for the perpendicular direction — an extremely dangerous practice blessed by the city’s authorities (again, by refusal to ever enforce infractions).
I’m glad we’re at least trying to make some forward progress here, but strongly suspect that Market St will still feel extremely dangerous for dangerous for pedestrians and bicyclists alike well into the foreseeable future. IMO, we should be more careful about letting city officials claim bold and innovative successes (as in the headline) while not really having changed much of consequence.
I think you're missing that most of the homeless presence is in specific areas, like downtown, where there are not many free restrooms.
Private businesses see a lot of abuse of their restrooms — from people using them and not paying for anything, but also because they make good places to do drugs, and it's common for homeless to overstay their welcome and/or damage the facilities. As a result, many businesses put locks on them and require that paying customers ask for a code.
There are a few publicly provided restrooms, but they tend to be few, far between, and in pretty sorry disrepair. In SF for example, you can find restrooms in parks and libraries, but they're often a mess. There are some single use restrooms on the street that were designed to provide autonomous self-cleaning public facilities, but because of abuse, nowadays they're mostly either out-of-order or have a full-time worker to babysit them (also, there's not many of them, and there throughput is very low).
Comcast is a terrible company in pretty much every way, shape, and form, but xfinitywifi has been useful to me many times now as a usable fallback when nothing else is available.
Better OS-level tools to manage these connections (i.e. intelligently not connect and flag as degraded) when the signal or backing network is extremely weak would be a huge boon though.
> If your career consists of Ruby->Node.js->Go then static binaries are radical new technology.
Rather than offer what amounts to nothing more than an ad hominem, perhaps you’d care to explain why whatever you’re using is superior.
Your preference may be containers or bytecode bundles, but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.
> You have to remember that most people there have started at the same place you're at right now. You even said it in your post.
So this is the part I disagree with. Everyone gets nervous doing public speaking, but there are some of us who get really nervous to the point that physical symptoms are, without a word of exaggeration, debilitating. Just getting up in front of that room and giving a crappy talk would have been very, very hard.
> That sounds like a goldmine of knowledge and experience to learn from. Find someone from that group who is willing to mentor you. Heck, the Leadership booklet has a checklist with one of the items being to mentor someone.
You're right, and I really don't want to slight the group here -- the interactions I had and everyone I spoke to was extremely supportive, it's just that getting spun up to their level would have an incredible daunting order even give months/years of work. I should give it another shot, but I just didn't see a path forward there at the time.
Going to Toastmasters seems to be the universal Internet standard advice for improving public speaking, but I'm not so sure about it.
I'm coming from a similar place of intense public speaking anxiety as the parent poster, and so attended my local Toastmasters, and at the first session mostly just observed. The hour was ~20 people who have been doing this for years giving highly refined talks to each other.
It was somewhat valuable seeing good speakers in their element, but to someone like me who's coming in with unrefined speaking manners and an anxiety problem, it was a total no-go. It probably varies by chapter, but I realized that Toastmasters wasn't a support group for bad speakers, it was a group of good speakers working to become great speakers.
That's not to say they wouldn't have been supportive and all, but in my opinion Toastmasters isn't an environment for overcoming anxiety at the low end. Of course, your mileage may vary.
For me, ads broke the informal social contract between provider and end user years ago. Small, unobtrusive advertisements might've been okay, but ads eating an inordinate amount of my time and bandwidth, which exfiltrate my personal information, and which are served to me via SEO tricks and dark patterns are not okay. If sites want to ban me for not viewing their ads, fine. In the meantime, I won't lose any sleep over using my adblocker.
For you, if you are lecturing us on the moral imperative of viewing ads, then you better be viewing those ads yourself rather than only espousing cheap rhetoric.