Smartness and happiness are like test coverage.
If you are not smart or have no tests, you will not be happy.
If you are smart or have high test coverage, you may or may not be happy.
Readit Newsspawarotti commented on Why aren't smart people happier? theseedsofscience.pub/p/w... · Posted by u/zdw
There are two types of people: those who do backups, and those who will do backups.
spawarotti commented on AGENTS.md – Open format for guiding coding agents agents.md/... · Posted by u/ghuntley
At this point AGENTS.md is a README.md with enough hype behind it to actually motivate people to populate it with contents. People were too lazy to write docs for other people, but funnily enough are ok with doing it for robots.
This situation reminds me a bit of ergonomic handles design. Designed for a few people, preferred by everyone.
And a related page, in the other direction: https://www.futuretimeline.net/
Very good online course on debugging: Software Debugging on Udacity by Andreas Zeller
spawarotti commented on Database mocks are not worth it shayon.dev/post/2024/365/... · Posted by u/shayonj
Don’t code with mocks period.
Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell).
Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO.
IO should be a dumb layer as much as possible. It should be Extremely general and as simple as fetching and requesting in the stupidest way possible. Then everything else should be covered by unit tests while IO is fundamentally not unit testable.
If you have a lot of complex sql statements or logic going on in the IO layer (for performance reasons don’t do this if you can’t help it) it means your IO layer needs to be treated like a logical layer. Make sure you have stored procedures and unit tests written in your database IO language. You code should interface only with stored procedures as IO and those stored procedures should be tested as unit tests in the IO layer.
Great advice. I follow it in my coding efforts and it has never failed me. Great book about this: Unit Testing Principles, Practices, and Patterns, Vladimir Khorikov, 2020
spawarotti commented on Serialization for C# Games chickensoft.games/blog/se... · Posted by u/jolexxa
In my personal projects I’ve been using variations on the same simple code for saving/loadings objects for a decade or so, and have very few problems. The heart of the code is this interface -
public interface IStashy<K>
{
void Save<T>(T t, K id);
T Load<T>(K id);
IEnumerable<T> LoadAll<T>();
void Delete<T>(K id);
K GetNewId<T>();
}
There’s a small number of gotchas, for which I have well known work arounds:
- I generally won’t remove a property, but mark it as obsolete and stop using it.
- If I’ve added a new Boolean property, I’d tend to name it such that it defaults to false, or if it must default to true, have it stored in a nullable boolean, and if it loads as null (from an older instance of the type), set it to the default.
- some convenient types I want to use (as properties) are not serializable, so before saving I’ll copy their data into a serializable type, like an array of key values, then on loading rehydrate that to a dictionary. (I guess this is a harsh performance penalty if you’re doing a lot of it in a game)
How do you deal with serializing properties "by reference"? E.g., if 3 objects reference object "Foo", then Foo is serialized once instead of being duplicated in the json 3 times?
I am especially excited for the Smart ComboBox:
https://devblogs.microsoft.com/dotnet/introducing-dotnet-sma...
In general, I see the idea of semantic matching instead of textual matching as one of the great, pragmatic applications of the current technology.
Somewhat related fun application of this concept is this: https://neal.fun/infinite-craft/ (the combination outputs are generated by LLMs)
That is sad, and I write that as someone who has been close to the edge: https://jakeseliger.com/2024/01/23/will-things-get-better-su... due to medical challenges.
Death leaves a hole in the social world that can never be filled.
Jake, I just read the blog post you shared. I loved it. The message and the writing style.
The big problem with documentation is that if it was accurate when it was written, it's just a matter of time before it goes stale compared to the code it's documenting. And while compilers can tell you if your types and your implementation have come out of sync, before now there's been nothing automated that can check whether your comments are still telling the truth.
Somebody could make a startup out of this.