I thought we weren’t supposed to call it “blacklist” or “whitelist” anymore?
This article was written before Year Zero
Things you should do now (2011)
41–50 of 115 posts
Re: Things you should do now (2011)
#42Earlier quoted context omitted.
You can encode it to a shorter string if you use larger alphabet. Still, it's 16 bytes of information, so not as short as sequential IDs. See for example https://pypi.org/project/shortuuid/ >>> shortuuid.uuid() 'vytxeTZskVKR7C7WgdSP3d'
Those shorter strings can come with their own caveats. Long-form UUIDs have the nice property of being URL-safe - but IIRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs. For correct semantics, short UUIDs have to go in the request parameters instead.
> IRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs.
That would break with any webserver that is serving files from a case-sensitive filesystem. Which is most of them.
Re: Things you should do now (2011)
#43For me #1 would be to add a version to any data format or communication protocol. If you want to know how hard not doing so can bite, don't look further than Git and it's tourcherous migration from sha1.
are there good examples for this, and how it scaled across versions over time?
This covers the wider problem of contract (protocol) changes in distributed systems:
https://aws.amazon.com/builders-library/ensuring-rollback-sa...
> With each change, we explicitly assign a distinct version to serializers.
> We do this independent of source code or build versioning. We also store the serializer version with the serialized data or in the metadata. Older serializer versions continue to function in the new software. We find it’s usually helpful to emit a metric for the version of data written or read. It provides operators with visibility and troubleshooting information if there are errors. All of this applies to RPC and API versions, too.
Backwards compatibility and the ability to roll out new changes (that can co-exist with current data) are the primary drivers.
Re: Things you should do now (2011)
#44Earlier quoted context omitted.
This topic is pretty close to flamebait so it gets downvoted would be my guess.
Yes, but why? How? I'm a non-native-speaker as well, and these things might be obvious to you, but they aren't to me. Is it a "should not use it", "must not use it", "maybe" or "it's fashionable"? How bad would it be if I accidentially use it, more like a four-letter-word or more like "well, he's a foreigner, he doesn't know"?
It totally depends on context and the culture of the people you are communicating with. Safest option is not to use it
Re: Things you should do now (2011)
#45Earlier quoted context omitted.
this, also there's no possibility of collision. You can't have two processes generate the same ID (which means you can generate your IDs in code and send them to the database, which is really useful in some situations). Also, and this is the main one for me - if I mess up my code and accidentally use a document_id instead of a user_id, I'll just get "not found" instead of someone else's data.
Actually, afaik uuids are pseudo-random and can thus absolutely collide in theory. Collision is solved by every db backend out there.
Many shops (I presume, since I work at non-FAANG) have their own version of UUID generation that includes info about the machine/instance it was generated from. I don’t think we’ve formally proved it but I think ours is guaranteed unique in our fleet.
Re: Things you should do now (2011)
#46Earlier quoted context omitted.
A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.
If you are implying that having an un-guessable URL secures your data, you might want to reconsider that approach. Your data should be secured server-side based on the actual auth in your app.
Not the OP but I read it as “much harder to scrape” than making it Secure. Which has some value.
Re: Things you should do now (2011)
#47Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
No you should not.
UUIDs are not always a good solution.
If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help.
You would need to sort by created_at and this would require an additional index.
No to speak of pagination by id ranges or whatever is used sometimes.
UUIDs are mpossible to remember and thus somewhat cumbersome to use too.
The weird id mixed up with index problem from the article is something which never happened to me ever in over 10 years of web development.
I stay away from PHP as much as possible so that may be the reason ;)
Re: Things you should do now (2011)
#48Don't use a raw integer as the ID type. Use different types for different IDs: UserId, OrganizationId, etc.
It's a common bug to get different ID types mixed up, and a gigantic offset will do nothing to help you with that.
Re: Things you should do now (2011)
#49I thought we weren’t supposed to call it “blacklist” or “whitelist” anymore?
Serious answer: this is still very much in flux. We're not at the point where you'd get audible gasps from using these terms, but in certain audiences you'll get some raised eyebrows.
If you believe that having "black=bad, white=good" connotations built into our jargon is harmful in some way, then yes, you should strive to use alternate terms.
If you don't think that's harmful, and you're forceful in defending "black=bad, white=good" as being too established and too inconvenient to change, that's when you're likely to get pushback.
Personally I've been trying to use "deny-list" and "allow-list" (with partial success – changing your jargon is hard). They feel a bit clunky, but I suspect that clunkiness will fade with time.
Re: Things you should do now (2011)
#50Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
No you should not. UUIDs are not always a good solution. If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help. You would need to sort by created_at and this would require an additional index. No to speak of pagination by id ranges or whatever is used sometimes. UUIDs are mpossible to remember and thus somewhat cumbersome to use too. T…
Integer ID's are always a bad thing.
Yes, you should be sorting things by created_at. Having another index is not a bad thing.
> The weird id mixed up with index problem from the article is something which never happened to me ever in over 10 years of web development.
How do you know? It's a remarkably difficult bug to detect.