codebeaker

Way to exclude mainland Europe through your short-sighted decision to use Imperial units.

There's simply no valid reason (and hacked in a weekend doesn't cut it) to store units in Imperial, let me choose, as as an engineer I abhor laziness in building such sites, in 2012, more than ever I18n and L17n are more important than ever, even within sites only offered in English language.

(plus the maths on converting weights is more sane with metric units, I just don't get it)

And overkill for almost all intermediate sized installations, but a great use of their technology to meet their requirements, thanks for the link.

Of course Twitter have snowflake: https://github.com/twitter/snowflake and many other tools such as UUID[4r] - see an old discussion on HN: http://news.ycombinator.com/item?id=1396667

Of course I wanted sequential, small IDs, within a small margin of acceptable loss (if a save fails that ID is never used), that were't taking up a massive amount of space.

> Sorry, but slugs serve a real purpose, so your solution is only a solution in the sense that walking is a solution for a broken down car.

This doesn't replace slugs, at all - the slugs are still generated, this replaces the SQL unique sequencer. The SQL sequencer which isn't universally supported, and has a different API on every platform.. many modern applications have Redis or a similar atomic structure store which could provide an interim solution, short of building a purpose built ticket provisioning system such as that employed by Flickr.

I'm weighing in here on the comments about "Solving a problem that doesn't exist" - the database is quite loaded, and we have Redis in the stack anyway. The solution to this problem is any backend which creates unique numbers atomically; I happened to choose Redis because I'm interested in it technologically and I like the API.

It's worth mentioning that Rails doesn't encourage access to the underlying database features - and that stepping outside of the Rails/ActiveRecord results in features which are difficult to test and more difficult to maintain in the face of an ever changing API.

I don't care where the next atomic ID comes from, as long as it comes from a datastore that is fast, and that I can trust.