161–170 of 199 posts
Earlier quoted context omitted.
Does this help see what's wrong with UUIDs in URLs? A GitHub issue URL in a parallel universe: https://github.com/a73ba12d-1d8b-2516-3aee-4b15e563a835/e16957bf-7d7f-41f1-97f4-98c93a6c3540/issues/4e4e9133-bcdb-45b9-8dfe-9e951846e3c6
I see bad url design for other reasons but nothing wrong with UUIDs, so no it doesn’t help me see the argument.
https://colab.research.google.com/drive/1ec4n7Ex9bnkl_c45EUl...
Earlier quoted context omitted.
There is no fundamental tech advance that caa make the birthday paradox irrelevant or obsolete, and there never will be.
all of cryptocurrency relies on sha256 the fact that the space is huge, and just ignores collisions. seems to work fine.
Earlier quoted context omitted.
Base32 or Base36 have the advantage of using single case which is easier to read out. And no symbols.
The official Base32 doesn't work for encoding UUID7, which is time-ordered, because its symbols for 0-31 are not in ascending ASCII order. My own preferred format for UUID7 is one I call "id25". It's really Base35 because alphabets of 35 and 36 characters both need 25 characters to represent the 128 bits in a UUID. So I can start with Base36 and take out one of the next most ambiguous character pairs. The result look…
Most of the use cases I can think of where I'd want an ordered UUID, I probably wouldn't need to lexically compare the encoding of multiple such IDs (where I can see plenty of utility in the ability to compare the underlying IDs).
There are so many nuances and edge cases not mentioned in the article. The author needs to do several projects in real life before making global pronouncements like this.
There are so many nuances and edge cases not mentioned in the article. The author needs to do several projects in real life before making global pronouncements like this.
The lack of humbleness and respect for devs who have came before you and solved all these problems is coming through strong. But I myself was that way 15 years ago. It takes a lot of hard lessons to realize everything new is old and we truly stand on the shoulders of 7000 giants all standing on each others’ shoulders.
My title is too presumptive. Yet, the reality for almost everyone who doesn't interface with other systems that already require UUID is that.
The brief article gives some points – backed by trustworthy sources – and shows some alternatives without further ado. I didn't spend days writing it. I could cover many more scenarios but didn't invest my time in it. So what?
Earlier quoted context omitted.
> that the average end user cares to be dealing with any random string of numbers and digits. A developer, which I took to be "the user" for the purposes of this writeup, cares. My small concern is that the rand is insufficient to generate a unique enough string (just use a lib like snowflake to get overkill entropy), but I'm sick of having the format at all for inconsequential ids (eg https://www.uuidgenerator.net/…
Also as a developer I really dislike UUIDs because the hyphens make it impossible to double-click copy. It’s a small gripe, but I need to copy IDs multiple times per day and it adds up. Other ID formats like cuid or KSUID don’t have hyphens in their canonical representation, and it makes them far more pleasant to work with
if not it might just become a situation of optimizing for your own workflow. and considering how ubiquitous uuids are and how common dash delimiters are outside of that(jira ticketscome to mind) maybe it would be better to fix places where double click selections do not include dashes instead of trying to avoid dashes in identifiers?
Earlier quoted context omitted.
> Does it make the URL in the URL bar longer? Yeah, but does that matter? Yes. That's one of the author's arguments. ) A simple ID like 3c6n63N is more than enough to represent any product while keeping it readable and making communication easier. A UUID alternative like a73ba12d-1d8b-2516-3aee-4b15e563a835 is just wasteful from an user’s perspective.
The point of a UUID is to have a unique machine ID that can be generated in parallel by separate, non-synchronized processes. You don't need to make it a user exposed identifier, and you can have a centralized (but out-of-the-critical-path) process assigning friendly IDs if you can afford visibility delays (for either the whole item or at least the friendly ID, which if it is the only user-facing locator may mean tha…
Others have noted the usefulness of generating ids for user-created data without involving the server, while being able to post that data at a later time without worrying too much about collisions.
Suspenders-and-belt practice would of course dictate that the server do some type of collision detection and mitigation before storing the received data.
If UUID exists in database and user ID is different, tell client "Yo, we've got a collision here. Your new ID for this data is blah".
Generate new UUID. If I've ever used that UUID before, generate a new one.
If the server rejects my UUID, switch to the new one provided by the server
Personally, I'd look on home-brewed solutions for generating unique "friendly ids" with the same deep suspicion I look at home-brewed crypto, particularly if this were done client-side for multiple clients without involving a server round-trip. Getting it right is a Hard Problem. The perceived complexity of UUIDs is there precisely because it is a Hard Problem.
Earlier quoted context omitted.
Plus I could easily represent UUID in base64, such as JlEt5BSYe0enwB7nxl5V6g, which makes it shorter if I need that.
Maybe use a smaller alphabet though, base64’s can be quite hard to read / spell out / reproduce as it includes confusing pairs. While somewhat less dense, base58 or rfc 4648 base32 mitigate these issues.