1,771 karma · joined October 10, 2013
Durable Execution offers three key benefits:
It improves application reliability by providing fault tolerance.
It simplifies code by allowing it to focus on the goal instead of potential problems.
It accelerates development by eliminating the need to write complex error-handling logic.
So... like exception handling? or something like erlang's let it crash mantra?Why is it such a big deal? Genuine question, not trying to be snarky
Mind if I ask which mode were you playing? Was it "Find a country" or "Guess a country"? It might be due to the countries being too small. I maintain a separate small countries list [1] from the bigger ones [2]
[1] https://github.com/kmcheung12/geo-dude/blob/main/public/data...
[2] https://github.com/kmcheung12/geo-dude/blob/main/public/data...
I didn't come up with a good way to show small countries so it is the way it is. Would love to hear suggestion though!
I just turned the repo public for your reference.
Country list at https://github.com/kmcheung12/geo-dude/blob/main/server/coun...
Picking a question from a continent is shuffle and then pick question per round, so "pick without replacement" https://github.com/kmcheung12/geo-dude/blob/main/server/inde...
Disclaimer, used a lot of AI so I didn't read every line of code
I made a similar but uglier little party game https://geo-dude.com for my kids. Supports up to 4 players
1. is very doable. My local gym uses an app to manage monthly leaderboard already and people seem to like it. There is a friendly rivalry in my local gym where people "fight" for the top spots
2. A lot can be done from the helping beginner angle. A coach told me he wishes to show hip placement and movement to young climbers, as it is easier to show than to tell an 8yo. I thought of doing inverse kinematics from holds to resolve body positions, so I get beta (sequence of moves) for each problem right away. Too hard, don't know if it is solvable.
A bit tangential, I think in theory the climbing wall with a set of problems is itself an identifiable code. We might get rid of the QR code too. I can create an index of visual features that resolves to a camera position, raycast from camera position to narrow down to maybe 3-5 problems, and select videos from there. But I digress.
For outdoor problems, I imagine it will be more like a map, and recording be taken with a drone. This is in contrast to the climbing magazine with plain photos of route.
I also think the usefulness decline as climbing ability increase. At the end of the day, climber just want to climb. But maybe there is some strava angle I can explore.
Appreciate your feedback, thank you!
As a climber myself, to climb effectively, one has to review their own climb, and with other people. 4D video, body positions across time, is very helpful in improving climbing. I managed to get a reasonable result (far from good) from one video, rather requiring multiple camera angles.
Haven't gotten to monetization yet, but I am enjoying every moment of making it.
A read only preview at https://kmcheung12.github.io/climb-preview/w/ae43c6e5
Writing code with one user is the base case of a “why am I writing this” recursion - because I use it.
Every action leads to next insight. For me, a browser extension that provides a table of content to chat interfaces because I always need to scroll up and down to read preview queries. Writing browser extension leads me to writing a RSS reader navigating with only keyboard. Writing RSS reader leads me to writing a virtual book shelf that visualize Goodreads record on a virtual 3D bookshelf. Writing virtual book shelf lead me to making a virtual climbing gym where I scan my local climbing gym into 3D model where I can map climbing videos on it. And it is just one chain
On the other hand, if we want a 3D reconstruction of a route in general, using a drone, then that's very doable. We still rely on 2D climbing magazine/book/app to view a route, where the contour of the route itself is highly desirably imo.
https://kmcheung12.github.io/climb-preview/w/a6ece004
I think 3D application is massively under utilised. There is whole family of interaction the textual web cannot provide
- Testing involving models is slow. It runs all your migration. Python's own "Unittest" is fast for functions not involving models.
- The suggested pattern for business logic is "active record", which is putting functions about a model alongside the model itself. Good for clean case. Doesn't really work when your operation involve multiple models.
- But if you put function about a model inside a model, the migration doesn't serialize the function into migration history (I could be wrong)
- "Data" migration is handy when you want enum-like data in database available to all teammates. e.g. list of currencies
- It is very tempting for new team member just to create an django app, with its own view and model, because it feels like starting a fresh without needing to care about existing business context. On the other hand, designing conceptual boundary between apps is very important. Because starting app is easy, and often (not always) wrong.
- The squash migration utils are limited because I guess of relatively low usage. It squashes linear migration history (with manual curation of starting and ending migration node I think? Not sure about latest state). I wrote a util to squash whole migration history by finding linear segments and squash those segment of history one by one. Didn't release it, but wrote some notes https://gist.github.com/kmcheung12/08b4c234b38c23efd43550da9...