Shawn Rainbow
@shawnrainbow.bsky.social
Android Dev, Kotlin Multiplatform Enthusiast, Math PhD
Geodesics on spheres are always arcs of great circles. Geodesics on a cylinder can be segments of spirals, though.
Geodesics are (in one definition, at least) the shortest distance paths between two points on a surface.
Geodesics are (in one definition, at least) the shortest distance paths between two points on a surface.
October 23, 2025 at 7:34 AM
Geodesics on spheres are always arcs of great circles. Geodesics on a cylinder can be segments of spirals, though.
Geodesics are (in one definition, at least) the shortest distance paths between two points on a surface.
Geodesics are (in one definition, at least) the shortest distance paths between two points on a surface.
I personally keep all my app modules together in an app folder (so technically they are submodules of :app), and also stick a kmp :app:shared module in there as the entry point for all of the platforms. Then everything else is just pure kmp modules (no "shared" prefix needed)
October 22, 2025 at 6:08 PM
I personally keep all my app modules together in an app folder (so technically they are submodules of :app), and also stick a kmp :app:shared module in there as the entry point for all of the platforms. Then everything else is just pure kmp modules (no "shared" prefix needed)
The very first infinite combo I discovered on my own while building decks in Magic the Gathering
September 19, 2025 at 8:47 PM
The very first infinite combo I discovered on my own while building decks in Magic the Gathering
Which is all to say that @johnoreilly.dev is right here, but it applies 100x more when someone raises an issue about clarity and confusion.
If someone says they don't understand a process, then the documentation of that process needs to be created or updated, etc.
If someone says they don't understand a process, then the documentation of that process needs to be created or updated, etc.
September 19, 2025 at 4:19 PM
Which is all to say that @johnoreilly.dev is right here, but it applies 100x more when someone raises an issue about clarity and confusion.
If someone says they don't understand a process, then the documentation of that process needs to be created or updated, etc.
If someone says they don't understand a process, then the documentation of that process needs to be created or updated, etc.
After thinking about it for another minute or two, I realized he couldn't be wrong. A piece of code is confusing if someone reads it and is confused, which was the case here. Objectively, he had to be right to at least some degree.
September 19, 2025 at 3:57 PM
After thinking about it for another minute or two, I realized he couldn't be wrong. A piece of code is confusing if someone reads it and is confused, which was the case here. Objectively, he had to be right to at least some degree.
Neat. What defines a "valid" location? Not within a distance of r from any other point?
September 5, 2025 at 7:26 PM
Neat. What defines a "valid" location? Not within a distance of r from any other point?
Birth cerificate: born Jan 01, 1970 at midnight on null island to parents "" and "".
August 29, 2025 at 3:54 PM
Birth cerificate: born Jan 01, 1970 at midnight on null island to parents "" and "".
Arguments and return values of your service methods should be models and not services.
Constructor injected objects should be services (most of the time).
The "glue" in this article is going to include the things that do actually take services as arguments/return values (like your DI framework).
Constructor injected objects should be services (most of the time).
The "glue" in this article is going to include the things that do actually take services as arguments/return values (like your DI framework).
August 23, 2025 at 9:12 AM
Arguments and return values of your service methods should be models and not services.
Constructor injected objects should be services (most of the time).
The "glue" in this article is going to include the things that do actually take services as arguments/return values (like your DI framework).
Constructor injected objects should be services (most of the time).
The "glue" in this article is going to include the things that do actually take services as arguments/return values (like your DI framework).
Services/injectables should have their own unit tests.
Models/newables are tested implicitly by the unit tests of the services they're used in, and thus shouldn't need their own unit tests.
Models/newables are tested implicitly by the unit tests of the services they're used in, and thus shouldn't need their own unit tests.
August 23, 2025 at 9:09 AM
Services/injectables should have their own unit tests.
Models/newables are tested implicitly by the unit tests of the services they're used in, and thus shouldn't need their own unit tests.
Models/newables are tested implicitly by the unit tests of the services they're used in, and thus shouldn't need their own unit tests.
Knowing this difference is important if you are trying to write clean testable code w/ dependency injection:
Services/injectables should always be injected as a dependency where they are used and you should use test doubles where they are injected.
Models/newables should never use test doubles
Services/injectables should always be injected as a dependency where they are used and you should use test doubles where they are injected.
Models/newables should never use test doubles
August 23, 2025 at 9:04 AM
Knowing this difference is important if you are trying to write clean testable code w/ dependency injection:
Services/injectables should always be injected as a dependency where they are used and you should use test doubles where they are injected.
Models/newables should never use test doubles
Services/injectables should always be injected as a dependency where they are used and you should use test doubles where they are injected.
Models/newables should never use test doubles