https://www.wired.com/1997/11/chaos-in-britannia-ultima-face...
247 karma · joined February 4, 2019
https://www.wired.com/1997/11/chaos-in-britannia-ultima-face...
And I had no clue this site existed, but Anabaptist World news has no exciting news related to anything tech [2] (though that is kinda expected).
Use the best tool for the job.
Certain situations might call for a timestamp instead of a boolean, especially if it is a value that is only ever turned on once and never turned off, possibly `user_deactivated_at`; I do prefer having a bit field and a separate timestamp for things that can flip; and for a lot of use cases it is good to just have a full event stream implementation where you can construct the state at any point in time and you get events data combined with the timestamps.
[1] https://en.uesp.net/wiki/Morrowind:Pemenie_and_the_Boots_of_...
[2] https://en.uesp.net/wiki/Morrowind:Cuirass_of_the_Savior%27s...
Language servers helped with some of this. You can write a standard language server that does a very good job and pool the talent of the entire community to add small useful features, instead of having to write a new implementation even if you just want to create a new editor.
Just the other day I saw a comment on HN about wanting something like the whytool, as well as having a way of seeing whether a function has any possible path of being called to/from the current function. Those are very useful features, but would require a large platform of language analysis to build on.
It would be nice if language servers had that as a supported feature, but seems like a difficult problem to solve. The naive approach would be to store every mutation in memory and where in the code it happened, but that might have horrific memory and performance considerations.
For the ancestor/descendant checks, the naive approach would be to have a recursive "find usages" check that checks if it ever hits the target, but, again, going anything past a trivial number of recursions could have an explosion in memory usage and time cost.
But one workflow for it would be open source projects that prefer not to have to maintain additional infrastructure and just want to inline ephemeral communication w/o having to keep it forever; then they make a design decision and have everything that is finalised moved over and documented in the wiki.
Then the core members don't need to have a dedicated channel somewhere else. If they did, then that would be another inbox to check; instead they can check the fossil chat when they are on the project site looking over commits or documentation.
So it is just another source of information on the main "fossil channel" instead of another channel to check. Viewing it in that way, it is reducing the number of channels by simply inlining it.
ORMs are a dependency that are often constantly updated, prone to corner cases, and require a lot of library specific knowledge-- but they often make code more secure against small mistakes or tossing in a string interpolation, which is important when working with others, especially junior developers. They can be quite nice to work with in having type checked queries, building up queries from pieces using an API, but they also tend to be heavy and miss some features of your DB.
Raw SQL on the other hand, is very flexible, standard, easy to read, and anyone who knows SQL can jump in. You can do REPL for queries and copy in, and edits to SQL are easy. The only dependency you need is the standard database drivers, and updates don't typically break things. If you have a basic understanding and use it right, security is great as well.