111–120 of 146 posts
On a serious note, I'm a bit surprised that GitHub makes it trivial to compute the rate at which new repositories are created. Isn't that kind of information usually a corporate secret?
Haha, he’s renamed it from “shit” to “repository” which makes the comments less funny
Reminds me of the 100 millionth OpenStreetMap changeset (commit). A few people, myself included, were casually trying for it but in the end it went to someone who wasn't trying and just busy mapping Africa! Much more wholesome, seeing it with hindsight. This person was also previously nominated for an OSM award. I guess it helps that openstreetmap doesn't really allow for creating crap, because it's all live in produ…
A friend of mine spent an entire workday figuring out how to ensure he created the millionth ticket in our help desk. Not sure how he cracked it in the end but we had a little team party to celebrate the achievement. This was probably fifteen years ago. I feel like working in tech was more fun back then.
Awesome! Only a little over a billion more to go before GitHub’s very own OpenAPI Spec can start overflowing int32 on repositories too, just like it already does for workflows run IDs! https://github.com/github/rest-api-description/issues/4511
The company where I did my stint as CTO I turned up, noticed they were using 32-bit integers as primary keys on one of their key tables that already had 1.3 billion rows and, at the rate they were adding them, would overflow on primary key values within months… so we ran a fairly urgent project to upgrade the IDs to 64-bit to avoid the total meltdown that would have ensued otherwise.
I wish I were still at Apple. Probably most people here know that Apple uses an internal tool called "Radar" since, forever. Each "Radar" has an ID (bug #) associated with it. Radars that were bug #1,000,000, etc. were kind of special. Unless someone screwed up (and let down the whole team) they were usually faux-Radars with lots of inside jokes, etc. Pulling up one was enough since the Radar could reference other Ra…
I think there's probably a lesson in there about schema design...
Earlier quoted context omitted.
Just curious as someone with limited experience on this. Whats wrong with it? decimal is consistent & predictable (compared than float), so it shouldn't be that big of a deal right? CMIIW
Yeah, not a big deal but completely useless nonetheless as you would never really query your table for just the one decimal column (eg the price) but a couple more (eg the category and the price) so you'd have a multi-column index on those columns. The index on just the price column never gets used.
Earlier quoted context omitted.
Is there any reason for GitHub to hide this information though? How could it be used against them? (I understand many companies default to not expose any information unless forced otherwise.)
Companies usually hide this type of information so competitors have a harder time determining if they are growing/shrinking/neutral.
Earlier quoted context omitted.
It's pretty easy to game this. Just keep creating repos till you hit # one billion and remove the old ones. Their API makes it trivial. The only issue will be rate limits, and other people simultaneously creating repos, so it's a matter of luck.
There was a guy who got fired from Meta for creating excessive automated diffs in pursuit of a certain magic number
Earlier quoted context omitted.
Yeah, not a big deal but completely useless nonetheless as you would never really query your table for just the one decimal column (eg the price) but a couple more (eg the category and the price) so you'd have a multi-column index on those columns. The index on just the price column never gets used.
What if you wanted to select "top 100 most expensive products" or number of products between $0.01 and $10, $10.01 and $100, $100.01 and $1000? Sure you could do a full table scan on your products table on both queries but an index on price would speed both queries up a lot if you have a lot of products. Of course you have to determine if the index would be used enough to make up for the extra time on index update wh…