Just remove the work part man. It's incredibly frustrating when you run out of money. Add some credit card loan or something and your final score is the amount of money you have left. Also, add teleport button—I clicked the big red button thinking it would transport me instantly. Only to be dropped off to in the middle of nowhere. And when you select a departure from train station, it should auto-select the end-stop, so you don't have to scroll down and click it (which is non-obvious btw that you have to)
The reason you have to work is because the game is based on a BBC show called "Race across the world" where you have to race from point A to point B with the money equivalent of an air fare for the journey.
If you run out of money in the show or your funds are running low you can work to earn more money. So that's why I added that feature. I do think it adds a extra layer to the game as it's something you always have to think about
It's good to follow an example but what works in a TV show can make for a bad game mechanic. Games like geo-guesser are nice because they focus on the fun part, figuring out locations. And leave the rest out. Learning real routes and prices is cool, playing fictional waiter is IMO not.
Well I want to give shadcn some credit, building a comprehensive open-source UI toolkit, on your own basically, isn't as easy as one would think. Yeah you can use native elements except for some tiny edge case with say Safari and then you go deeper into the rabbit hole, until you decide you'll just customize everything. But at this point you probably have lost a lot of time and sanity already.
I'd put the blame on React and poor Web APIs in this case. Both are way too complicated for mere mortals to understand fully, and even simplest things like maintaining 100% container height through nested elements, can become a ridiculous time-sink for something completely unrelated to what is your main objective.
Well. Coming from TS, Gleam just wasn't/isn't my jam. It's a nice programming language research project, but it just goes against the grain for me a little too much. All the made-up rules early returning always being weird `use` call, the type boilerplate—no inline object types as I remember. Lot of inventions that just makes me go "why?" Like the opposite ideology of Go. And yes I've used Haskell before (didn't like it) and Rust (kinda like it) and others in smaller quantity.
I am more excited about making things rather than fetishizing about some language paradigms so, I acknowledge that Gleam just isn't for me. I did give me the insight that for me, it might be the best to stick with the common denominator languages for the foreseeable future.
While he has a point and Italians are kinda embarrassing in their politics, can't help the feeling that he comes off as a bit of cry-baby. Trying to win points with the JD/Musk mafia that hard seems weird and icky. Seems like signaling to other billionaire bros that they belong to their faction, which in my books isn't that great either. That last uppercase line a cherry on top of shattering my image of CF as respectable tech-vendors.
Those science studies are a load of bull if they say added sugar up to 50 GRAMS has no effect on your health. Your gut develops a craving for it like no other and your insulin spikes much harder when you intake that much on daily basis. When you're off sugar for a while, you notice how those "compulsions" you have during groceries is just due to your gut yearning for some sugar. Now fruits and natural sugar are a lot better, but even them I wouldn't consume excessively if you are in the business of high focus -work.
Strange the article proposes itself for "Enterprise" yet has no mention of Google's Zanzibar and how it compares to the other approaches. AFAIK it doesn't use pre-computed values but just queries really fast (using Spanner so there's that)
Google's Zanzibar actually does both: for the vast majority of queries, it uses significant levels of caching and a permitted amount of staleness [1], allowing Spanner to return a (somewhat stale) copy of the relationship data from local nodes, rather than having to wait or coordinate with the other nodes.
However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cache called Leopard that is used for a very specific subset of these relations [2]. For SpiceDB, we called our version of this cache Materialize and it is designed expressly for handling "Enterprise" levels of scale in a similar fashion, as sometimes it is simply too slow to walk these deep graphs in real-time.
Ooh, and back when that was not a thing (iirc a few years back) me and a friend of mine had built a spiritually similar index for spicedb for our final year project at uni. We had a mini WAL and the ability to safely reject queries that specified a minimum update requirement after the index updation.
In SpiceDB, this is known as the LookupResources [1] API, which returns all resources (of a particular type) that a particular subject (user in this case) has a particular permission on.
We have a guide on doing ACL-aware filtering and listing [2] with this API and describing other approaches for larger Enterprise scales
Disclaimer: I'm the co-founder and CTO of AuthZed, we develop SpiceDB, and I wrote our most recent implementation of LookupResources
We actually have users that synchronize their resources from various sources (AWS, Kubernetes, etc) into SpiceDB, explicitly so they can perform these kinds of queries!
One of the major benefits of a centralized authorization system is allowing for permissions queries across resources and subjects from multiple different services/sources (of course, with the need to synchronize the data in)
Happy to expand on how some users do so, if you're curious.
Worth mentioning Casbin as well (https://github.com/casbin/casbin) - it's been around for a while and takes a slightly different approach. Instead of being purely Zanzibar-inspired, it uses a PERM (Policy, Effect, Request, Matchers) metamodel that lets you implement RBAC, ABAC, or ReBAC depending on what fits your use case.
The blog post is actually much more rational than some of the comments here. There's a fine balance what I call fetishization of tools and just knowing your craft well. Sometimes, we want to use an abstraction even though simpler approach may be better because we are in hurry, want to learn new things or just dont care particularly.
Whose to judge if it works and ships on time? Well, the fool later down the road who has to maintain it probably. But I've never believed in gate-keeping or preaching without pragmatism - I rather put my energy in teaching what little i can and hope that joy of seeing things improve for better will motivate them towards learning. If not, well it's waste of time either way.
reply