Max Volume
@maxvolume.app
Makes things from code and/or wood, rides bikes and waves. Fascinated by machines since the Commodore 64 days. Trying to teach my small humans to ask great questions.
Try turning on “proximity fade” in your fog material, that should get you halfway there:
docs.godotengine.org/en/latest/tu...
docs.godotengine.org/en/latest/tu...
Standard Material 3D and ORM Material 3D
Introduction: StandardMaterial3D and ORMMaterial3D(Occlusion, Roughness, Metallic) are default 3D materials that aim to provide most of the features artists look for in a material, without the need...
docs.godotengine.org
December 21, 2025 at 11:28 PM
Try turning on “proximity fade” in your fog material, that should get you halfway there:
docs.godotengine.org/en/latest/tu...
docs.godotengine.org/en/latest/tu...
I’m left-handed, some appreciate ijkl instead of wasd.
June 17, 2025 at 10:30 AM
I’m left-handed, some appreciate ijkl instead of wasd.
Really final thought - don't worry about any of this, unless you can prove with measurements that you have a performance problem here.
January 31, 2025 at 1:10 AM
Really final thought - don't worry about any of this, unless you can prove with measurements that you have a performance problem here.
Final thought - DBs are pretty good at caching too. It might be ok to always call exists?, since that query might be really fast if you've already preloaded the association.
January 31, 2025 at 1:09 AM
Final thought - DBs are pretty good at caching too. It might be ok to always call exists?, since that query might be really fast if you've already preloaded the association.
If there is a performance issue (e.g. high volume and expensive queries), I'd also explore alternative options. In the case of feature flags or user access rights, I'd consider caching those (as arrays per user) in the rails cache.
January 31, 2025 at 12:52 AM
If there is a performance issue (e.g. high volume and expensive queries), I'd also explore alternative options. In the case of feature flags or user access rights, I'd consider caching those (as arrays per user) in the rails cache.
That would depend on how costly it is to load the association, and if it is expensive to do, how often the "cold" case occurs.
I don't think it's worth micro-optimising for the "association is not preloaded" case.
I don't think it's worth micro-optimising for the "association is not preloaded" case.
January 31, 2025 at 12:51 AM
That would depend on how costly it is to load the association, and if it is expensive to do, how often the "cold" case occurs.
I don't think it's worth micro-optimising for the "association is not preloaded" case.
I don't think it's worth micro-optimising for the "association is not preloaded" case.
2. This looks to be a minor optimisation in the best case (select 1 … query vs. association load), but at worst you’ll execute many select 1 queries, one for each feature you need to check existence for. If you use .any?, the association is loaded once and cached, so you’ll only have one query.
January 30, 2025 at 9:42 PM
2. This looks to be a minor optimisation in the best case (select 1 … query vs. association load), but at worst you’ll execute many select 1 queries, one for each feature you need to check existence for. If you use .any?, the association is loaded once and cached, so you’ll only have one query.
1. I use association extensions all the time. Also see the rails guide: guides.rubyonrails.org/association_...
Active Record Associations — Ruby on Rails Guides
Active Record AssociationsThis guide covers the association features of Active Record.After reading this guide, you will know how to: Understand the various types of associations. Declare associations...
guides.rubyonrails.org
January 30, 2025 at 9:38 PM
1. I use association extensions all the time. Also see the rails guide: guides.rubyonrails.org/association_...
I think Swift has done a great job of addressing these over time with structured concurrency and actor isolation. The discussions on the swift concurrency proposals (and the proposals themselves) are pretty good, if I remember correctly.
January 25, 2025 at 1:20 AM
I think Swift has done a great job of addressing these over time with structured concurrency and actor isolation. The discussions on the swift concurrency proposals (and the proposals themselves) are pretty good, if I remember correctly.
I’d also add a category for concurrency-related errors, eg. race conditions, locking, isolation
January 24, 2025 at 11:27 PM
I’d also add a category for concurrency-related errors, eg. race conditions, locking, isolation
It's a good example!
If maintaining backwards API compatibility was important, and out of spite, I'd probably fix it like this: 😜
If maintaining backwards API compatibility was important, and out of spite, I'd probably fix it like this: 😜
January 17, 2025 at 12:04 AM
It's a good example!
If maintaining backwards API compatibility was important, and out of spite, I'd probably fix it like this: 😜
If maintaining backwards API compatibility was important, and out of spite, I'd probably fix it like this: 😜
If we wanted to allow users to re-lock the chest, we could alternatively return nil from lock_chest as well. Depends on requirements…
January 16, 2025 at 10:31 PM
If we wanted to allow users to re-lock the chest, we could alternatively return nil from lock_chest as well. Depends on requirements…
lock_chest is public, and will return the new secret when called - the last statement of a ruby method without an explicit return statement is implicitly returned.
“private” in line 20 will prevent lock_chest from being called from outside a treasurechest instance.
“private” in line 20 will prevent lock_chest from being called from outside a treasurechest instance.
January 16, 2025 at 9:37 PM
lock_chest is public, and will return the new secret when called - the last statement of a ruby method without an explicit return statement is implicitly returned.
“private” in line 20 will prevent lock_chest from being called from outside a treasurechest instance.
“private” in line 20 will prevent lock_chest from being called from outside a treasurechest instance.
Also: raise exceptions, mutate global variables, send messages to method parameters.
December 22, 2024 at 3:19 AM
Also: raise exceptions, mutate global variables, send messages to method parameters.
The rooftop ruby podcast had a good episode on that very recently.
I like ZenVer: github.com/NotAShelf/Ze...
(Change the version whenever you feel like it, basically)
I like ZenVer: github.com/NotAShelf/Ze...
(Change the version whenever you feel like it, basically)
ZenVer/spec at main · NotAShelf/ZenVer
A post-modern versioning scheme that does not suck. - NotAShelf/ZenVer
github.com
December 15, 2024 at 4:09 AM
The rooftop ruby podcast had a good episode on that very recently.
I like ZenVer: github.com/NotAShelf/Ze...
(Change the version whenever you feel like it, basically)
I like ZenVer: github.com/NotAShelf/Ze...
(Change the version whenever you feel like it, basically)
I’d rename the method to something like “grant_public_access_if_already_accessible_to_everyone” or some variation of that.
The problem is that “grant access to everyone” omits the very important condition that it _already_ needs to be accessible to everyone.
The problem is that “grant access to everyone” omits the very important condition that it _already_ needs to be accessible to everyone.
December 12, 2024 at 4:34 AM
I’d rename the method to something like “grant_public_access_if_already_accessible_to_everyone” or some variation of that.
The problem is that “grant access to everyone” omits the very important condition that it _already_ needs to be accessible to everyone.
The problem is that “grant access to everyone” omits the very important condition that it _already_ needs to be accessible to everyone.
We used to say at my company that when all you have is a hammer, everything looks like a singleton.
But I do think Current Attributes are a great approach for a bunch of “this should be somehow global” problems.
And it’s not dirty until you tell someone about it ;)
But I do think Current Attributes are a great approach for a bunch of “this should be somehow global” problems.
And it’s not dirty until you tell someone about it ;)
December 9, 2024 at 3:29 AM
We used to say at my company that when all you have is a hammer, everything looks like a singleton.
But I do think Current Attributes are a great approach for a bunch of “this should be somehow global” problems.
And it’s not dirty until you tell someone about it ;)
But I do think Current Attributes are a great approach for a bunch of “this should be somehow global” problems.
And it’s not dirty until you tell someone about it ;)
Turns out that using synthetic data for large scale load testing is not a good idea, so I broke mobile banking for a quarter of people on a whole continent.
Fortunately, being able to spin up a ridiculous and expensive amount of replica databases very quickly, that only lasted 30 minutes.
Fortunately, being able to spin up a ridiculous and expensive amount of replica databases very quickly, that only lasted 30 minutes.
December 7, 2024 at 3:55 AM
Turns out that using synthetic data for large scale load testing is not a good idea, so I broke mobile banking for a quarter of people on a whole continent.
Fortunately, being able to spin up a ridiculous and expensive amount of replica databases very quickly, that only lasted 30 minutes.
Fortunately, being able to spin up a ridiculous and expensive amount of replica databases very quickly, that only lasted 30 minutes.
I really enjoyed your article, thanks for all the work you put in!
Although it probably should have been titled “NodeJS can succ my Int” ;)
Although it probably should have been titled “NodeJS can succ my Int” ;)
December 6, 2024 at 10:21 AM
I really enjoyed your article, thanks for all the work you put in!
Although it probably should have been titled “NodeJS can succ my Int” ;)
Although it probably should have been titled “NodeJS can succ my Int” ;)
Persist, definitely.
In my experience, there’s only ever one correct way to model something. If you find yourself building a shortcut around that, you will almost certainly regret that later.
In my experience, there’s only ever one correct way to model something. If you find yourself building a shortcut around that, you will almost certainly regret that later.
December 5, 2024 at 3:37 AM
Persist, definitely.
In my experience, there’s only ever one correct way to model something. If you find yourself building a shortcut around that, you will almost certainly regret that later.
In my experience, there’s only ever one correct way to model something. If you find yourself building a shortcut around that, you will almost certainly regret that later.
From my own experience, if someone tells you that the app needs to be rewritten in XYZ because of FRAMEWORK, it’s not because of FRAMEWORK. It’s normally because they screwed it up so badly they don’t want to deal with it anymore.
https://FRAMEWORK.it’s
December 4, 2024 at 9:36 AM
From my own experience, if someone tells you that the app needs to be rewritten in XYZ because of FRAMEWORK, it’s not because of FRAMEWORK. It’s normally because they screwed it up so badly they don’t want to deal with it anymore.
Of course. But you need to guard against clients acting in bad faith, which is not what the robustness principle is about.
It’s about accepting mildly shitty input and being nice about it. But there’s always bobby tables: xkcd.com/327/
It’s about accepting mildly shitty input and being nice about it. But there’s always bobby tables: xkcd.com/327/
Exploits of a Mom
xkcd.com
December 4, 2024 at 8:42 AM
Of course. But you need to guard against clients acting in bad faith, which is not what the robustness principle is about.
It’s about accepting mildly shitty input and being nice about it. But there’s always bobby tables: xkcd.com/327/
It’s about accepting mildly shitty input and being nice about it. But there’s always bobby tables: xkcd.com/327/